Two of the most important communication protocols used on the Internet and other similar networks are the Transmission Control Protocol (TCP) and the Internet Protocol (IP). Together, the TCP and IP protocols form core protocols of the larger Internet protocol suite used on packet-switched networks. That protocol suite is commonly referred to as the TCP/IP protocol because of the widespread adoption and implementation of the TCP and IP protocols.
The TCP/IP protocol was developed for the United States Advanced Research Projects Agency (ARPA). The TCP/IP protocol is a set of rules that enable different types of network-enabled or networked devices to communicate with each other. Those network devices communicate using TCP/IP standards, or formats, to transfer or share data. TCP/IP rules are generally established and maintained by the Internet Engineering Task Force (IETF). The IETF is an international community of network designers, operators, vendors, and researchers concerned with the Internet's architecture and operation. The IETF's mission is to produce technical and engineering documents that influence the way people design, use and manage the Internet with the goal of improving its operations and efficiencies. These documents include protocol standards, best current practices and information updates of various kinds, and are commonly referred to as Request for Comments (RFC).
TCP can be used to establish a bi-directional connection between two clients wherein activity begins with a request for information made by one client to another client. A “client” is any program or application that initiates requests for, or sends, information from one remote location to another. As used herein, the term “client” may refer to applications including, but not limited to, web browsers, web servers, file transfer protocol (FTP) programs, electronic mail programs, line printer (LPR) programs also known as print emulators, mobile phone apps, and telnet programs also known as terminal emulators, all of which operate conceptually in an application layer.
The TCP protocol is typically implemented as a “daemon” that is part of a TCP/IP stack of protocol layers. A daemon—also sometimes referred to interchangeably as a server or service—is generally a software component of a device that runs a background process. As used herein in relation to the operation of the TCP protocol, the term “daemon” is used to refer to a component of a networked device that sends (source daemon) or receives (destination daemon), and processes communications between remote clients according to the TCP standard.
A host is a device or system that runs or executes TCP/IP daemons. As used herein, the term “host” refers to any such device or system including, but not limited to, a server platform, a personal computer (PC), and any other type of computer or peripheral device that implements and runs TCP software. Generally, a host physically connects and links clients and daemons to TCP/IP networks, thereby enabling communication between clients.
TCP software accepts requests and data streams directly from clients and other daemons, sequentially numbering the bytes, or octets, in the stream during the time the connection is active. When required, it breaks the data stream into smaller pieces called segments (sometimes referred to as datagrams or packets) for transmission to a requesting client. The protocol generally calls for the use of checksums, sequence numbers, timestamps, time-out counters and retransmission algorithms to ensure reliable data transmission.
The IP layer actually performs the communication function between two networked hosts. The IP software receives data segments from the TCP layer, ensures that the segment is sized properly to meet the requirements of the transmission path and physical adapters (such as Ethernets and CTCs). The IP layer changes the segment size, if necessary, by breaking the segment down into smaller datagrams, and transmits the data to the physical network interface or layer of the host.
The network connecting devices are generally called gateways. These gateways communicate between themselves for control purposes. Occasionally, a gateway or destination host will communicate with a source host, for example, to report an error in datagram processing. For such purposes the Internet Control Message Protocol (ICMP) is used.
If the objective is to use the Internet service protocols to covertly deliver a payload, the payload's point of origin should remain secret and unobserved. Current protocols either expressly make the origin of a data payload known or easy to obtain. While it is possible to mask the payload transmission through encryption or other deceptive means, the discovery and observation might well lead back to the host of origin even if the payload is undeterminable. In other words, for a payload of data to be truly covert, the point of origin should be masked, potentially in addition to other protections offered during transmission.
Therefore, what is needed is a system and method for delivering information from one host to another while masking the payload's point of origin. The present disclosure provided a system and method for covertly transmitting a payload of data from one host to another by making the payload's point of origin.
One of the most effective methods to mask operational functions is to utilize the underlying TCP/IP protocols as they were designed, without alteration or augmentation. Furthermore, when properly implemented, the disclosed system and method may utilize an unsuspecting host as a supplanted replacement for the point of origin without the host's knowledge or participation. A discrete unit of information (the “payload”) may be transmitted from an origin host to a destination host by way of a blind host. Preferably, the blind host is unaware of its involvement. The traffic coming from the blind host may appear to be the sole origin of the data. The blind host may have no record of the existence of the origin host. The net result of the process may be the delivery of a payload which appears to have originated at the blind host. In this way, the location and identify of the payload's true point of origin, the origin host, may remain undisclosed.
Such covert transmissions may be accomplished by using the blind host's requirement to produce error messages when it receives network traffic that appears to be in error. The origin host may create a datagram that contains a payload of information intended for covert delivery to the destination host. Rather than send this datagram directly to the destination host, the origin host may be configured to direct the traffic to the blind host. However, the source addresses in the datagram header may indicate that the datagram originated at the destination host. Furthermore, the datagram may intentionally contain a fatal flaw that will require the blind host to generate an error message and return it to the address indicated as the source—i.e., the destination host. Since the source address within the datagram in error indicates the destination host's address, the blind host may transmit the error message to the destination host. The error message may contain enough of the original datagram to include the payload intended to reach the destination host covertly.
By using this blind bounce back technique, it is possible to communicate between two hosts without directly forming a communication path or revealing the true origin of the message(s) containing the payload. By intentionally creating an error within the datagram with the incorrect source address, the blind host may bounce the message containing the payload back to a location that did not originate the message. The resulting process may leave the true origin of the message undetectable by involving an unrelated and unwitting participant in the transmission.
Further features and advantages of the systems and methods disclosed herein, as well as the structure and operation of various aspects of the present disclosure, are described in detail below with reference to the accompanying figures.